26 February 1997
Source: http://www.bxa.doc.gov/24-.pdf (2,783K)

Public Comments on Encryption Items Transferred from
the U.S. Munitions List to the Commerce Control List

24. Microsoft

Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Tel 206 882 8080
Telex 160520
Fax 206 936 7329

February 13, 1997

Nancy Crowe
Regulatory Policy Division
Department of Commerce
14th Street and Pennsylvania Avenue, N.W.
Room 2705
Washington, D.C. 20230

Re: Microsoft Comments on Encryption Regulations

Dear Ms. Crowe:

On behalf of Microsoft Corporation, I hereby submit comments on the interim final rule: "Encryption Items Transferred from the U.S. Munitions list to the Commerce Control List" published in 61 Fed. Reg. 68573 (Dec. 30, 1996) (hereinafter the "New Encryption Regulations"). As you may recall, Microsoft submitted detailed comments on a draft version of these regulations that was provided to Sandra McKinnon as a PECSEA member on very short notice. To the extent that you improved the final version of the regulation based in part on our earlier comments, we thank you. In particular, establishing License Exception KMI for exports of 56 bit encryption products, not requiring distributors to requalify to export KMI shipments of the same software, and clearly delineating "other recoverable encryption products" as a category separate from "key escrow" and "key recovery" encryption products showed responsiveness to some of our concerns. Much more work remains to be done to make the New Encryption Regulations realistic and effective export controls. In this letter, we have amplified on those of our prior comments that you did not address and have provided recommendations to help you improve this rule further.

General Comments on Policy and Procedures

Our specific Comments set out below are mostly directed at improving the New Encryption Regulations within the context of the Administration's policy announced in October 1996 and implemented via Executive Order 13026 and a Presidential Memorandum issued by President Clinton on November 15, 1996 (although we also propose several policy changes). Although we wish to work with BXA to help you improve the New Encryption Regulations, let us also be clear that we continue to reject the policies set forth in those Presidential documents. Far from being the "liberalization" of export controls on encryption items that the Administration touted, the New Encryption Regulations create a Virtual ITAR within the EAR by establishing the new EI controls and denying encryption software all of the basic protections offered by the EAR against egregious and ineffective controls.

Like the ITAR, these new EI controls are constitutionally suspect. Apart from authorizing exports of 56-bit products if companies commit to development of key recovery products, the New Encryption Regulations do not allow exports of any products that could not already have been shipped under licenses issued pursuant to the ITAR. And, a new license reviewing agency, the Justice Department, seems likely to slow down the license review and approval process from that experienced under the ITAR and possibly restrict license approvals even further. We are on record advising the Administration again and again why these policies are ill conceived and are doomed to failure if not restructured to meet current market realities. Our general comments below explain why,

A. Other Letters, Papers, and Reports Explain Why 40 and 56 Bit Solutions are Inadequate

I am attaching copies of recent letters from the Business Software Alliance to Vice President Gore and to Bruce McConnell and Ed Appel, which accurately reflect Microsoft's views on both key recovery policy issues and the need for further export liberalization of non-key-recovery products. I am also enclosing a paper by Matt Blaze of AT&T Labs (Draft of 27 December 1996), which presents a high level technical analysis of the Administration's current policy. It and the National Research Council and BSA papers it references explain quite clearly the technical reasons why 40- and 56-bit encryption key levels are woefully inadequate, to protect today's information economy and why the "key recovery" approach is far too expensive and unwieldy to provide a viable basis for mass-market software of the type that Microsoft distributes.

The most promising marketplace now and for the future is the Global Information Infrastructure. Security in the GII is essential for this market to develop and thrive. More and more businesses require increasingly sophisticated electronic communication and the freedom to secure communications via robust mass-market encryption products. Requirements for information security apply to financial institutions, under privilege, and consumers using their credit cards to shop. These and other applications and users require strong encryption products to ensure that transactions are valid, not subject to tampering, and private.

The National Research Council ("NRC") study, "Cryptography's Role in Securing the Information Society" (1996), called for unconditional liberalization of export controls on 56-bit DES at minimum, stating:

The current export regime on strong cryptography [licensing generally only exports of 40 bit DES products] is an increasing impediment to the information security efforts of U.S. firms competing and operating in world markets, developing strategic alliances internationally, and forming closer ties with foreign customers and suppliers .... Consistent with the rising emphasis on the international dimensions of business (for both business operations and markets), many U.S. companies must exchange important and sensitive information with an often changing array of foreign partners, customers, and suppliers. Under such circumstances, the stronger level of cryptographic protection available in the United States is not meaningful when an adversary can simply attack the protected information through foreign channels.

Similarly, Microsoft, and other BSA member companies, have long advocated that exports of mass-market products should be decontrolled to a minimum of 56-bit keys for data encryption and 1024-bit keys (public key algorithms) for key exchange, as well as 128-bit data encryption keys and 1024-bit key exchange keys for Internet financial applications.

B. The Administration Has Not Proposed a "Market Driven Solution" as It Claims

The NRC study stressed the importance of adopting a market driven encryption policy to meeting users' needs and providing for user choice:

A national cryptography policy that is aligned with market forces would emphasize the freedom of domestic users to determine cryptographic functionality, protection and implementations according to their security needs as they see fit. Innovation in technologies such as escrowed encryption would be examined by customers for their business fitness of purpose. Diverse user needs would be accommodated; some users will find it useful to adopt some form of escrowed encryption to protect their access to encrypted data, while others will find that the risks of escrowed encryption (e.g., the dangers of compromising information through a failure of the escrowing system) are not worth the benefits.

Although the Presidential Documents and the New Encryption Regulations speak as if they are embodying a market driven focus, this is not the case, the NRC study recommended complete decontrol at 56-bits at a minimum. The Administration has instead offered a limited decontrol whose benefits are restricted to companies that commit to developing encryption products that support key recovery solutions of a specific type that excludes the very key recovery solutions that the marketplace has demanded. But this policy falls fails to reflect market realities for three reasons:

1. Lack of industry input. Although the New Encryption Regulations encourage industry participation in the design of recoverable encryption products, the Administration has barely changed the criteria for exportable escrow systems since they were first proposed by NIST in 1995. Despite countless hours of industry input to improve them, our words seem to have fallen on deaf ears and, with rare exceptions, are not reflected in the Administration's new policy.

2. Lack of customer demand. Customers, especially large corporations, view key recovery features as necessary for systems that encrypt stored data. Notwithstanding the legitimate interests of law enforcement in wiretaps, however, customers have not expressed any interest in recovering "session" keys used to encrypt communicated data. Corporate customers (except in a few highly regulated business contexts such as securities or commodities trading) and individual end-users derive no benefit from recovering encrypted communications and, therefore, are unwilling to bear the substantial costs and risks associated with building and maintaining such systems (see Matt Blaze, "Cryptography Policy and the Information Economy," Section 4). No mere change in terminology can mask this critical flaw in the Administration policy. the New Export Regulations limit permissible exports to key escrow solutions that customers have overwhelmingly chosen not to adopt in the past, and restrict export of the very key recovery solutions that the marketplace has demanded and will continue to demand. As we have heard from our customers countless times, the legitimate and market driven demand for key recovery in the public sector is for solutions limited to stored data only that permit the user or enterprise to self-escrow, or to voluntarily escrow keys with the third party of their choice.

3. Lack of easy export of 56-bit products. Even if the Administration had confined itself its new policy to stored data products, many vendors would remain reluctant to spend the funds necessary to develop and market key recovery products when their ability to deliver them to customers is dependent on a standardless, semi-annual review of product development plans, especially when the export authority for 56-bit non-key recovery products expires in two years and the conditions for ongoing service and upgrades remains uncertain.

C. Administration Policy is Based on a False Premise That U.S. Export Rules Can Drive Industry to Develop Narrowly Defined Key Escrow Products and the Market to Accept Them

The Administration's encryption policy assumes that the carrot of relaxed export controls is sufficient to induce industry to develop key escrow products that satisfy law enforcement requirements for access to communicated data, notwithstanding lack of customer demand. Considering the added cost and complexity associated with escrow encryption systems, it is not at all clear that decontrol of 56-bit non-key recovery products is enough of a carrot (or the termination of this privilege enough of a stick) to bring about the desired result. Moreover, even if these inducements were sufficient to force U.S. industry in this direction, this carrot and stick approach ignores two salient facts: first, that the emerging Internet standard for secure communications is 128-bit SSL, not 56-bits; and, second, that products incorporating 128-bit SSL are readily available both here and abroad, leaving non-standard, 56-bit products at a distinct competitive disadvantage.

SSL, which stands for Secure Socket Layer, is a communications protocol for transmitting encrypted data between a client and server (e.g., a browser and a Webserver). SSL utilizes RSA public key encryption (512 to 1024-bits) to negotiate and certify a server and then a fast, symmetric, bulk cipher (such as Triple DES or 128-bit RC 4) to encrypt the stream of transmitted data.Browser and server products incorporating 128-bit SSL are freely available in the U.S. from all of the major vendors, including market leaders such as Microsoft and Netscape, as well as from major on-line service providers and financial institutions engaged in electronic commerce. With 128-bit SSL already well on its way to becoming a de fact Internet standard the likelihood that domestic customers will change to more expensive and complex escrowed systems seems remote, absent legislation restricting encryption domestically,which the Administration has clearly stated it has no intention of sponsoring.

Nor is this market dynamic in any way limited to the U.S. A growing number of foreign vendors offer 128-bit implementations of SSL that are fully interoperable with export versions of U.S. products. How is this possible? To begin with, the specifications for the SSL protocol as well as 128-bit SSL reference source code are freely available on the Internet and in publicly available literature from both U.S. and non-U.-S. sources. Foreign vendors then utilize general purpose development tools and programming languages, which are freely exportable from the U.S., to design and implement cryptographic extensions or "middleware" to convert U.S. browsers or Web servers from 40-bit SSL to 128-bit SSL. For example, a German company called Brokat Systeme (http//www.brokat.de/xpresso/indexe.htm) offers a Java-based encryption toolkit for secure Internet banking and shopping, which implements '"highly secure 128 bit transaction encryption despite US export restrictions." A U.K. company called Stronghold (http://stronghold.ukweb.com/about/overview.php) tells customers that "if you buy a secure server from inside the USA you will get a crippled version that supports only 40 bit keys" whereas Stronghold offers "uncompromised, full 128-bit symmetric encryption in all versions" of its products (note that Stronghold makes-the second most popular commercial Web server for UNIX). These two sites are not alone in recognizing that U.S. export controls create a market opportunity for savvy developers.

Thus, there is a false premise at the heart of the Administration's policy; namely, that the world wide market for secure Internet products will stand still while U.S. vendors respond to (inadequate) incentives to develop (and then permanently transition to) escrow encryption systems. It is much more likely that the new commercial encryption policy will result in a lose-lose situation for industry and the U.S. government, with customers purchasing non-escrowed and key recovery products of a different, more useful and preferred design from foreign vendors over which the NSA exercises no jurisdiction or control.

D. The Administration Should Adopt the Following Policy Changes

The Administration should take the following four steps to keep U.S- software companies internationally competitive and enable customers worldwide to protect their information, thereby avoiding the lose-lose situation. described above:

1. Allow exports under EAR License Exception TSU (without a written assurance) of mass market software programs without restriction, at least at the minimum levels of 56-bits for data encryption and 1024-bits (public key algorithms) for key exchange.

2. Allow exports under EAR License Exception KMI of programs using unlimited strength encryption provided they address both-commercial demand for recovering stored data only and address law enforcement's needs for access to such data in criminal investigations.

3. Index control levels to allow them to change automatically as technology levels make them obsolete by adopting a cost of cracking adjustment ("COCA"). Having to achieve political level solutions every few months is wasteful and inefficient for government and business.

4. Allow exports under License Exception TSU of Internet and other electronic commerce financial applications software at a key length level minimums for data encryption of Triple DES or 128-bit RC4 (or similar algorithms) and 1024-bit for key exchange.

These solutions would fit the current market, whereas the Administration policy is out of touch with market realities. Indeed, the reemergence of strong backing for legislative initiatives to liberalize export controls on encryption products demonstrates that the Administration's encryption policy does not properly balance the need for strong cryptography by personal and commercial users and the legitimate needs of law enforcement and national security. We will be pursuing these policy issues in the coming months with top level administration and Congressional officials in order to help establish a more viable encryption export policy than what the regulations embody. We thought it important to convey these ideas to give you a realistic context for revising the New Encryption Regulations in order to come as close to meeting marketplace realities as current policies allow. The remainder of our comments will address the specifics of the regulations.

Specific Comments on New Encryption Regulations

For the most part, these comments follow the order of the regulations for convenience to those charged with their review and revision. We are willing to provide suggested regulatory language for any of these points to the extent we have not done so below.

1. Substantive Law Set Out in the Preamble/Supplementary Information but Not in the Regulations Should Be Included in the Regulations. Many provisions require clearer treatment in the body of the regulations that are only covered in the preamble section. Leaving exporters to look to an introduction in the Federal Register for substantive legal provisions makes the regulations less useful and less clear without the benefit of expert counsel who are steeped in such arcane matters. The following items should be included in the body of the regulations (some of which are discussed in more detail at the appropriate sections below):

1.1 Definitions of terms "Recoverable Items and Services" and the subcategories "Key Escrow Product", "Key Recovery Product", and "Recoverable Product" (Section 772).

1.2 Assurances that exporters can continue to service and sell additional 56 bit products exported under License Exception KMI after December 31, 1998 (740.8).

1.3 The statements that License Exceptions TMP and BAG effectively replace the State Department's personal use exemption and authorize exports of encryption software for personal use (740.9 and 740.14). At a minimum, include in ECCN 5D002 an indication that these License Exceptions are available and revise the last sentence in the first "Note" to ECCN 5DO02 to include the underlined portions in the following revised sentence :

"License Exceptions for commodities, other than TMP and BAG, are not applicable".

Otherwise, this phrase appears to take away authority to use TMP and.BAG.

1.4 Most fundamental, the statements that encryption software and technology controlled by the Department of Commerce prior to December 30, 1996 are not affected by the rule and will continue to be eligible for publicly available treatment and other treatment not accorded to "EI" controlled products need to be included in Section 742.15, or you should create a new Interpretation Section to cover this and other issues discussed below.

1.5 The Statement in the Preamble and Elsewhere that Encryption Software is Controlled because of its Functions and Not Because of Its Information Content and is Thus Different from Other Software is Absurd and Undermines Other Controls. This assertion is scattered throughout the New Encryption Regulations. This is a transparent bootstrap argument to try to improve the Administration's cases against challenges to the constitutionality of these rules. However, it create confusion in the regulations as to when software controlled by ECCN 5D002 is and is not eligible for export under provisions applicable to technical data. Moreover, the clear "distinction without a difference" actually could make all other software controls in the FAR vulnerable to constitutional challenge because they are said to be based on informational content of such software. Software has always been controlled based on its functional capabilities. Accordingly, the more likely effect of this bald assertion is to undermine the Administration's cases in court. We strongly recommend that the Administration drop these counterproductive provisions.

1.6 Delete All References to Controls on the "Plaintext of Encrypted Communications." This would comport with our General Comments above. This phrasing first appears in the preamble at pages 68573 and 68575. The substantive rule deletions to communications encryption controls should be made in Sections 740.8(d)(ii) and 742.15(b)(2).

1.7 The Administration Needs to Address the Deemed Export Rule for Foreign Nationals. One reasonable reading of the new EI controls is that they do not apply to disclosure of software to foreign nationals in the U.S. or the host country of a licensee because these products are treated as commodities, not technical data. We appreciate that the Administration made the commitment in the preamble to address what should be the application of controls on disclosure of software and technical data to foreign nationals. We are eager to work with the Administration on this project.

2. Revisions Made to Part 734 Scope of the EAR  Undermine the Credibility of Export Controls

2.1 Change the New Definition of Export of Encryption from a Per Se Liability Definition to an Advisory. BXA should back down from the per se rule of liability created by the new definition of "export of encryption source code and object code software" set forth in Section 734.2(b)(9) and adopt instead a "rule of reason". The new definition includes "making such software available for transfer outside the United States over wire, cable, radio, electromagnetic, photo-optical photoelectric or other comparable communications facilities accessible to persons outside the United States, including transfers from electronic bulletin boards, Internet file transfer protocol and World Wide Web sites." While many specialized export control practitioners had advised companies like ours that this was a potential interpretation of the law by prosecutors, government officials have never made this difficult and controversial issue a regulatory requirement (although there had been some written advice to similar effect by ODTC in response to questions raised by individual companies). This new definition has the effect of criminalizing everyday behavior such as high school kids uploading software onto bulletin boards or the operation of open Web sites and FTP sites, where people never think of themselves as "exporting". It is one thing for a company like ours to take the precautions outlined in the definition to avoid liability, but it is quite another for the government to make ordinary citizens criminals with the stroke of a pen. We strongly urge you to consider retaining the model standards of care as safe harbors, but to change this provision from an unrealistic definition of export to an advisory that, depending on all the facts and circumstances, such activities might be considered to aid and abet illegal exports.
At a minimum, BXA should delete the requirement that exporters seek specific written approval for other safeguards beyond those set forth in the model provisions. There is no reason to require everyone to ask and obtain such permission. Most citizens will not do so, so to require it simply criminalizes even cautious actions simply because one did not say "may I".  Large volume software providers who have concerns over risks will certainly seek advisory opinions from U.S. export control agencies, as Microsoft did in establishing the safe harbor provisions described in this section for Internet distribution of its web browser. The ITAR did not force us to seek the guidance that we obtained, and the EAR should not force others to do so if they are confident that the protections they devise will meet the standards set out or otherwise adequately limit their potential for liability. if the Administration insists on retaining this rule, BXA at least needs to Publicize it. The preamble did not mention it, and it is certain to surprise many computer users, Internet service and bulletin board providers, and others who do not think of themselves as exporting.

Finally, it would be helpful for BXA to clarify that the new affirmative acknowledgments as well as written assurances for TSR exports may be met by any means that establish such an understanding under commercial laws. Any manner of assurance or acceptance that is sufficient for the commercial marketplace should suffice for EAR records. Some BXA officials have had difficulties accepting modern commercial on-line techniques whereby the user clicks on an "accept" or similar button to provide an affirmative written assurance acknowledgment of restrictions on a product that the customer is about to obtain, or assurances in shrink wrap licensing agreements. Both have been widely accepted  in commerce, and there is no reason for BXA to try to micro manage such basic business practices.

2.2 Exemptions from Publicly Available Treatment Are Arguably Unconstitutional and Violations of the Berman Amendments to IEEPA. We will leave most of our comments in this area to the court cases currently challenging the constitutionality of these rules. Suffice it to say that freedom of speech is the bedrock of the U.S. Government; it is both bad policy as well as bad law to run roughshod over this fundamental principle. Worse than that, these attempts are ineffective and make U.S. export control law less credible. Encryption software is freely shared throughout the world by academics and users, regardless of what restrictions commercial companies like Microsoft put in place to make sure that we do not export it.

This exclusion is also a fundamental erosion of one of the basic principles of the Export Administration Regulations. As recently as September 1996, top level Commerce Department officials publicly explained how the EAR and BXA policy clearly recognized the fundamental right of exporters to place software in the public domain and thus place it outside the scope of the EAR.

Moreover, these provisions violate the Berman Amendments in Section 203(b) the International Emergency Economic Powers Act on which the Administration has relied to issue these regulations. (Pub. L. 100-418, S 2502(b)(1) (102 Stat. 1371), and Pub. L. 103-236, S 525(c)(1) (108 Stat. 474) ("Free Trade in Ideas"). Among other things, these provisions state:

"The authority granted to the President by this section does not include the authority to regulate or prohibit, directly or indirectly --
(1) any postal, telegraphic, telephonic, or other personal communication, which does not involve a transfer of anything of value;

* * *

(3) ... the exportation to any country, whether commercial or otherwise, regardless of format or medium of transmission, of any information or informational materials, including but not limited to, publications, films, posters, phonograph records, . . tapes, compact disks, CD ROMS, artworks, and newswire feeds."

The remainder of paragraph 3 specifies that items controlled for export under Section 5 or parts of Section 6 of the Export Administration Act of 1979 are not included in these exemptions. However, that Act has expired and attempts to create new controls under those sections via the authority of IEEPA cannot also exclude them from the provisions of IEEPA. The Administration has properly applied this law to exclude informational materials from other controls under IEEPA that are aimed at terrorist supporting countries. (See, e.g., 31 C.F.R. S 560-210(c) and .315 (Iranian Transactions Controls of OFAC).) Likewise,encryption software qualifies as informational materials whose export cannot be restricted under IEEPA.

2.3 Exemptions from De Minimis and Foreign Availability Requirements Undermine the Credibility of U.S. Export Controls. The national security controls for which the de minimis rule and foreign availability rules were developed as exceptions were aimed at protecting the western world from the threat of nuclear proliferation and possibly the annihilation of the U.S. or its European allies. The idea that encryption items pose an even more serious threat such that the de minimis and foreign availability rules must be waived strains credibility. The de minimis rules in Part 734.4 exclude from the scope of U.S. reexport controls items with less than 10 percent U.S. content. The U.S. Government established these reasonable restrictions on U.S. exercise of extraterritorial export control jurisdiction in recognition of the fact that excessive U.S. reexport controls were not effective and either (a) were not obeyed or (b) were inciting significant non-U.S. companies to 'design out' U.S. content to the extent possible. The foreign availability rules in Part 768 are riddled with loopholes, but are designed to allow decontrol of items only after a laborious finding that comparable products are available from sources outside of U.S. to such an extent that U.S. controls are rendered ineffective in achieving their intended purpose. The President can waive the application of the foreign availability finding, and it does not require mandatory decontrol of foreign policy based controls in any case. Excluding EI controls from such basic and marrow protections against regulatory overkill is absurd. We are in serious danger of forgetting hard-learned lessons that excessive and ineffective controls that do more harm than good for U.S. export and reexport controls.

3. License Exception KMI Does Not Realistically Apply to Mass Market Software (740.8)

We appreciate the fact that the interim final rule established this new license exception for key recovery products and non-key recovery products with a key length of 56 bit or less. We also appreciate your adoption of the provision in 740.8(d)(2)(iii) allowing applicants to inform distributors of their right to use authority granted for KMI-56 shipments without the need for them to apply separately and recognized other recoverable encryption products as a distinct category. Further improvements are required.

3.The Six-Month Successive Approval Provisions for 56 Bit Nonrecoverable Software, Should Be Replaced with a Two Year License Subject to Review of Bi-Annual Reports. Software developers will be more likely to develop software that meets the criteria for License Exception KMI for Non-Recoverable 56 Bit Products ("KMI-56") if we can obtain a full two year authorization that is revocable by BXA if required six month reports show they are failing to meet the criteria. The rights and benefits of a two year authorization would be the same as those under the interim rule's requirement for successive six month authorizations, but the government would have to revoke authorization rather than exporters having the burden of obtaining six month renewals. If adequate reports are not filed for the six-month review, the burden of revocation will be minimal for the government to meet, Thus, the legal risks to the exporter would not change. However, the economics of software development would. Products officially authorized for two years will be far more marketable, so software developers will more likely spend development funds to establish such products. Two years is not a long time, but a six-month authorization is almost nothing.

3.2 All Language Regarding Non-Recoverable KMI Eligible Software Should Refer to "56Bit or Less". Not "Up to 56 Bit" (Which Does not Include 56).This change should be made in Sections 740.8 and 742.15.

3.3 BXA Needs to Provide Self Executing Objective Criteria Rather than Requiring Individual Classification Requests for Eligibility to Export under License Exception KMI. The Interim Rule requires exporters to submit classification requests to be covered under three different provisions of the New Encryption Regulations: (a) that they meet Supplements 4 and 5 for key recovery and key escrow software, (b) that they meet the general standard of 740.8(d)(ii) for other recoverable encryption items", and (c) that their business plans for nonrecoverable encryption items meet the requirements of Supplement 7. This process requires case-by-case reviews of what each company submits. At minimum, the Provisions of Supplement 7 need to indicate what if any technical limitations other than 56 bit key length the exporters are required to meet (such as is the case for 40 bit items in Supplement 4). Moreover, industry is very concerned that case-by-case reviews of technical submissions and business plans will necessarily favor one company over another, especially given the relatively subjective standards for "other recoverable encryption items" and the aspects of business plans in Supplement 7 to Part 742 for KMI-56products. Each of these provisions should be clear, objective, self-executing standards. There should be no need for a case-by-case review (at least not where the standards are clear, such as for key recovery products). Instead, BXA should simply state that exporters must meet the criteria of the applicable Supplements and require a report and certification that those standards are met before one can be eligible to export under License Exception KMI. Exporters who are not certain they meet the criteria can always apply for Advisory Opinions, the traditional method for handling "gray areas" of the EAR.  BXA should encourage requests for Advisories by retaining the same fast track 15-day review of them.

Additionally, exporters need to have some assurance of equal treatment, and now they have none unless they follow the very restrictive approach of companies that decided to build products fully compliant with the NIST software key escrow criteria. The approach now taken in Supplement No. 7 is commercially unacceptable and represents an unnecessary and inappropriate government effort at setting  "industrial policy" (see Gore letter, page 2; McConnell and Appel letter, pp. 6-7.) Several specific elements of Supplement No. 7 are especially troubling. Companies must submit a plan regarding transition to products with "recoverable" features. Presumably, this phrase refers to key escrow, key recovery, and recoverable products. But Supplement No. 7 speaks only in terms of key recovery and key management infrastructure products. This, in turn, seems to rule out "recoverable products" from consideration for 56-bit licenses, which contradicts the statement in the preamble and other provisions. At a minimum, these provisions in Supplement 7 need to be clarified. Without explicit criteria on the requirements for exporting 56-bit "recoverable" products, Microsoft and other vendors are unlikely to commit any development or marketing resources to key recovery products of this type. In other words, the new export licensing policy will not -provide any incentive to build products consistent with government objectives because the lack of specific criteria makes licensing outcomes too uncertain.

3.4 Part 740.8 Needs to Include Assurances from the Preamble that Exporters will Be Allowed to Service Customers of 56 Bit Non-Recoverable Products after December 3, 1998 and to Export Further Products. The regulation itself utterly fails to address this major factor that every U.S. vendor must know to consider in developing any key recovery business plans. The statement in the preamble is helpful, but it should be made part of the law. Customers already demand assurances in advance that vendors will continue to offer upgrades, expansion of services, replacement for detective products and similar standard support of products. Likewise, the statement that exporters will continue to be able to ship such products after December 31, 1998 should be included in this section.

3.5 The Criteria for Key Recovery/Escrow Are Not Conducive to Key Recovery Software Development. The conditions for favorable consideration of key escrow and key recovery products reference Criteria for Key Recovery or Key Escrow Products (Supplement No. 4 to Part 742) and Key Recovery or Key Escrow Agents (Supplement No. 5). In general, the two supplements mirror (with only minor revisions) the November 1995 NIST Sponsored Software Key Escrow Encryption Export Criteria and the December 1995 NIST Key Escrow Agent Criteria. Microsoft's objection to these criteria are by now familiar (see, most recently, Gore letter, pp. 2-3; McConnell and Appel letter, pp. 4-8.). Indeed it is extremely disappointing that, while the Administration is touting this rule as a liberalization and the Vice President's October 1 announcement speaks in term of an "industry-led" technology strategy, scant progress has been made over the past year of dialogue in developing criteria for a voluntary and market-driven approach to key recovery. In fact, the New Encryption Regulations criteria for Key Recovery and Key Escrow products and the NIST Criteria on which they are modeled constitute an extreme narrowing of permissible Key Recovery solutions, which is patently inconsistent with industry's direction in this matter. Given the opportunity, industry would lead this technology strategy in a very different direction than has been offered by the Administration. The term "key recovery" is used as if it is different from the "key escrow" concept that industry found so objectionable, but it is hard to see any difference in the specific criteria other than a mere word change. It is helpful that the rule includes provisions for approval of "other encryption items", but it is difficult to conclude what will qualify if such products do not take on the features of recovery or key escrow products.

We have made these points many times since these standards were published by NIST in 1995 for public comment. As they have been essentially unchanged, we feel like we are wasting our breath.

3.6 Supplement 5 Criteria and Reporting Requirements of Section 740.8(e) Do Not Fit Mass-Market Software Distribution Models. The New Encryption Regulations generally ignore the realities of mass-market software distribution. Mass-market software publishers have invested hundreds of millions of dollars in developing multiple distribution channels such as OEMs (i.e., hardware manufacturers that pre-load software onto computers), value-added resellers, retail stores and the emerging channel of on-line distribution. The mass-market distribution model presupposes that software publishers will take full advantage of these multiple channels to ship identical or substantially similar products world wide (allowing only for differences resulting from localization) irrespective of specific customer location or characteristics. A mass market software product can be expected to sell in quantities of millions, tens of millions, even hundreds of millions in the case of essential software such as operating systems. The Supplement 5 Criteria are suited only to the distribution of products in the thousands of copies, at best. Neither the Supplement 5 criteria requiring specific knowledge of customers in order to qualify them as key recovery agents nor the section 740.8(e) reporting and record keeping requirements take any account of this model of distribution. Compliance with these rules would require a substantial change in current methods of distribution as well as the collection of downstream information that is neither readily available nor of any obvious utility to enforcement officials. Unless BXA implements a mass market exception to these rules or a transparent compliance mechanism based on current distribution models, mass-market vendors face yet another disincentive to developing key recovery products or even seeking interim licences for 56-bit non-key recovery products.

4. Clarify Personal Use Provision for License Exceptions TMP and BAG (740.9.14)

At page 68575, column 2 of the preamble, BXA states: "License Exceptions TNT and BAG effectively replace the Department of State's personal use exemption." It was clearly the intent of the regulation to have them do so. However, at least minor revisions would help clarify their application because BXA staff has been providing mixed signals as to whether TMP authorizes exports of encryption software to Country Group D: 1. Encryption software on a laptop of a corporate executive or other employee should be covered. by the "tools of the trade" provisions of TMP. However, a sentence at the end of EAR 740.9(a)(2)(ii) states that "only equipment necessary to commission or service goods may be taken as tools of trade to Country Group D: 1." The 23 countries in D: 1, including all the former U.S.S.R. countries and the PRC, have been eligible for exports under the ITAR personal use exemption. The grandfathering intent of the New Encryption Regulations indicates that this problem is a drafting oversight, and thus should not be the result of the New Encryption Regulations. BXA needs to clarify this point so that exporters will be on firm ground. The clearest revision would be to eliminate the quoted sentence as no longer relevant to post Cold War commerce and practice. Remember, the personal use exemption was established to decriminalize everyday behavior of U.S. travelers and others who unwittingly were violating the law whenever they traveled abroad with a laptop equipped with even a mass-market encryption software program. We find that the provisions of License Exceptions TMP and BAG would much more effectively replace the personal exemption with this modification.

5. Carve Out for General Software Note and BETA Provision of TSU (740.13) is Ineffective

One of the most egregious deviations from basic protections of the EAR against export control overkill is the carve out added to ensure that EI controlled encryption software programs are not eligible for export under License Exceptions TSU and BETA that authorize export to all but embargoed and terrorist supporting countries of all other mass market software programs that meet the criteria of the General Software Note. This carve out was wholly predictable, but is an unfortunate precedent and further indicates that the present regulation is no more than a Virtual ITAR dropped down amidst the EAR. The General Software Note was established multilaterally in COCOM and implemented by the United States in 1990. As Larry Christiansen has stated for the record on many occasions: "The theory underlying the GSN is that there is a subset of software that is so widely available to the general public that it is uncontrollable and therefore the COCOM governments should not impose an unmanageablc control burden on the firms subject to such controls."1  The U.S. had adopted this provision for "Free World Exports" in the late 1980s and convinced COCOM in 1990 to establish this free export treatment for all types of mass market software based on the recognition that such software could not be controlled effectively, regardless of the nature or the purpose of the controls over a given product. The primary export controls at the time were based on protection of national security and nonproliferation of weapons of mass destruction. The "G-BETA" provisions of TSU were simply extensions of this concept to cover beta test versions of what is expected to become mass-market software. Unfortunately, this Administration refuses to recognize that the fundamental characteristics of mass-market software products do not change merely because the product in question contains encryption features. These exclusionary provisions for EI controlled items should be deleted here and in Supplement 2 to Part 774.Encryption software is neither more important to control than items that once could have aided the Warsaw Pact's immense military threat to the Western World during the Cold War, nor any more capable of effective control than other types of software.

____________________

1. Larry E.Christensen,"Technology and Software Controls Including Recent Changes in Country Scope" Coping with US Export Controls 1995 365, at 385 (Practicing Law Institute 1995).

6. Basic Licensing Policy in 742.15 Needs Revisions for Clarity and Reality

We have commented in part 3 above on the provisions of Licence Exception KMI. These comments apply likewise to the related provisions in Section 742.15.

6.1 Include a Basic Explanation on How to Classify Products with Encryption Functions, Including When 5A002, 5D002, and 5E002 Apply, How Exemptions Move Classifications to 5A/D/E995 entries, and when EI Controls of 5A/D/E002 Apply. The classification scheme for encryption products under the New Encryption Regulations and the application of EI controls needs to be made much more clear for most exporters. It has taken those of us who are very sophisticated in this field too much time and careful parsing of the New Encryption Regulations to discern the logic of the new classification scheme, and no doubt many exporters remain confused. The following fundamental points should be made, either at the beginning of Section 742.15, the beginning of 742.15(a) with a new subsection (1) (renumbering the remainder), or by adding a new Interpretation in Part 770 and cross-referrencing it here.

6.2 Clarify Continuation of Past ODTC Practice that Proprietary and Certain Other Software Will be Considered for Removal from EI Controls in Addition to Mass Market 40 Bit Software. The language in Section 742.15(b)(1) and Supplement 6 needs to clarify what has long been the policy to allow case by case transfers from the ITAR (now the EI controls) of more than just 40 bit mass-market encryption products. Language in the regulation appears to contemplate similar treatment to what ODTC and NSA have granted for what is referred to in the summary as "proprietary software" that meets the 40 bit technical limits but does not qualify as mass market and thus may not be eligible for the7-day review process. Many types of software have been covered by the 15-day expedited ITAR Commodity Jurisdiction ("CJ") transfer process even if they do not qualify as mass market, and a great deal of software products that fall outside the limited parameters of Supplement 7 have also been the subject of approved transfers of export control jurisdiction to the EAR. Products that fall into this category may use the same algorithms and key sizes as products eligible for 7-day review, yet by virtue of ancillary modifications are pushed into the 15-day process. Likewise, ODTC and NSA have approved CJs for other products that do not meet the provisions of Supplement 6 to Part 742. These include mass-market software with strong encryption (64-bit keys or greater) functions that are limited to encryption of client-bank and bank-bank financial data. These and future products of the same types should receive the same treatment for removal from EI controls that ODTC and NSA have applied, and the Administration should retain the flexibility to remove from the "Virtual ITAR" EI controls other products that are similarly restricted. The language of the regulation as drafted falls short in covering this past practice because Supplement 4 simply lifts the language of a 1993 ODTC guidance handout without connecting it and updating it to reflect what has been actual practice of ODTC and NSA to date. These provisions should be corrected as follows:

6.3 To the Extent Possible, Create Objective, Self-Executing Classifications Rather than Requiring Case by Case Reviews for Each and Every Product. Supplement 4 as written provides an objective standard for mass market 40 bit encryption products. There is no need for exporters to submit classification requests for each and every product that meets these tests. Indeed, ODTC Filing Instructions for 7 and 15 Day Review advised that exporters do not need to have new releases reviewed under the predecessor CJ process, and likewise for other programs that use the exact same encryption functions that had previously been cleared. If exporters have any question whether these provisions apply, they can and will apply for Advisory Opinions, which can be encouraged by providing the same 15-day fast track review envisioned here. Case by case review will be needed for other programs, but there is no need to require it when an objective standard exists and will serve to reduce the burdens to both industry and government officials.

6.4 Restructure 742.15 (b)(l)-(3) To Clarify Non-Licensing Provisions and Shorten Confusing Overlap with License Exception KMI Provisions. Section 742.15(b)(1) is not totally a licensing provision and should clearly say so. A sentence should he inserted at the end stating: "To the extent that items released from EI controls are not eligible for export under License Exceptions (e.g., non-mass-market software with 40 bit key lengths), license applications will receive favorable consideration."

It is somewhat useful to have a fairly complete overview of the regulatory scheme for various types of encryption products in one place, but the creation of License Exception KMI calls for the provisions of Section 742.15(b)(2) and (3) to be shortened to more of a summary and cross reference with the provisions of Section 740.8. Those provisions that are not duplicated should be incorporated into 740.8. These overlapping provisions will otherwise create confusion as well as regulatory drafting problems for updates.

6.5 BXA Should Describe in Section 742.15(b)(4) the Favorable Consideration Licensing Policy Long Afforded to Exports for Financial Applications, Communications among Foreign Subsidiaries of U.S. Companies, and Other Precedents. The Vice Presidents statement of October 1 indicated that the New Encryption Regulations would continue the favorable export licensing considerations given to encryption products exported for financial end-uses and end- users and for communications among non-U.S- subsidiaries of U.S. companies. To avoid having these provisions branded as "paradigm of standardless discretion" (to coin a phrase), BXA should set out in this section of the EAR a description of this well known but to date unwritten policy of granting favorable consideration to license applications for strong, non-key escrowed encryption products for certain end-users and end-uses. While we believe that current policy is far too restrictive to meet commercial realities, it is one that should be clear to everyone. Otherwise, the New Encryption Regulations seem to imply that we are stepping backwards from that policy of licensing encryption items to the same end-users and uses that have been approved in the past.

Further, this policy should be updated and clarified to enable exporters to play on the same level field, while allowing for administration approval of evolving technologies and customers. In particular, financial transactions require much stronger (Triple DES and 128-bit) non-key recovery crypto because of their unique vulnerability to eavesdropping and exploitation for substantial financial gain. Given that non-financial applications will be approved under License Exception treatment at 56-bit key lengths, licensing policy for financial applications should step up to higher levels that are now demanded by financial institutions. Foreign financial networks are setting national standards at 128-bit encryption level, and foreign integrators are already supplying 128-bit cryptography solutions to foreign banks through middleware. It serves no purpose to put U.S. companies at a competitive disadvantage.

7. Delete Unconstitutional Restriction on Technical Assistance in 744.9

This provision is overly broad and not appropriate to encryption software. We appreciate that the interim final rule recognizes that teaching or discussion of information would not constitute assistance. Presumably, neither would the exercise of free speech, which is not otherwise controlled, but this is not clear. Methods to develop encryption software have been widely published since at least the 1960s. This provision undercuts the credibility of the regulations and serves no useful purpose.

There is no need to define "U.S. person" in this section. The same definition (other than the very limited category of "protected persons" appears already in Part 772 with the rest of the definitions. Delete Section 744.9(b) as redundant (and not necessary either).

8. Classifications Should Not Be Required, Advisories Should be Encouraged (748.3(b)(3))

As described above in our comments on License Exception KMI (740.8) and release from EI controls (742.15), the EAR should replace requirements that exporters seek classifications for each and every encryption product with objective, self executing standards. The regulation fails to appreciate the nature of mass-market software, where products proliferate on a daily basis. There is no need to imply that one must obtain classifications or one-time-reviews for each and every new release of a cleared product nor each new product incorporating approved encryption modules. Neither NSA nor ODTC has required this to date and anyway there are too many products for review. The EAR has developed a model for exporters to apply objective standards and self classify to the extent possible. When the application is questionable, exporters have the option to apply for advisory opinions. This is a far preferable model than the classification requirements embodied in this rule. Otherwise, we are harkening back to the days when license were required for the same products that are routinely approved. It would be far preferable to encourage applications for Advisory Opinions by retaining the 15-day review cycles set out in the regulations (rather than the standard 30-day time limits for advisories, to which BXA does not adhere).

9. The Justice Department Has No Place in the Encryption Licensing Process (750)

We understand that Justice and the FBI have an interest in encryption policy, but adding yet another reviewing agency to the already cumbersome interagency review and dispute resolution procedure is only disruptive. NSA has long been a vigorous defender of encryption controls, and has supporters in DoD, State, and ACDA. If DOJ and/or FBI are not eliminated from the review process, they at least should be specifically excluded from review of 5X002 products except those attempting to qualify for export under the KMI solution.

10. Foreign Availability Considerations Should Apply to All Export Controls (768)

As described above, it is bad policy and bad law to exclude encryption controls from procedures to determine whether comparable products are available from foreign sources to such an extent as to render unilateral U.S. export controls ineffective in achieving their intended purpose. There is little reason for U.S. officials to fear the application of already weak foreign availability assessment provisions. The President has the authority to waive any requirement of automatic decontrol of national security controls if foreign availability is found. Thus, excluding encryption controls from foreign availability assessments only serves the purpose of avoiding critical examination of whether these controls cause more harm than good. Moreover, the Export Administration Act mandates a watered down foreign availability assessment for foreign policy controls, which BXA has never incorporated into the EAR. Thus, the statement that Section 768 only applies to national security controls does not comport with the law that the President is purportedly applying via Executive Order.

11. Section 772 Needs to Define "Recoverable Encryption Items" and Related Terms

Unfortunately, the rule does not define the essential but overlapping terms for "recovery encryption items" and the three subsets thereof, "key escrow', "key recovery", and "recoverable", other than quickly in the preamble and via application in the New Encryption Regulations. The preamble to the rule defines "recovery encryption products" generically as "encryption products (including software) that allow government officials to obtain under proper legal authority and without the cooperation or knowledge of the user, the plaintext of encrypted data and communication. Such products fulfill the objectives of the Administrations encryption policy. Other approaches to access and recovery may be defined in the future." Supplements 4 and 5 to Part 742 clearly delineate certain basic requirements for key escrow and key recovery software (with no distinction between the two terms). These terms need to be defined as does the term "user" in the sentence quoted above. In general, the terminology used in the interim rule for describing various types of encryption items is confusing and, at times, inconsistent.

"Encryption items" is clearly the broadest term used to describe encryption commodities, software, and technology containing encryption features. But, because this term is used both generically and as a definition of controls, the generic definition in Part 772 and its uses creates confusion with the more specific "EI Controls". Distinct terms should be used rather than the same words to mean two different things.

The rule uses a variety of terms to describe the category of "encryption items" with recovery features. These include:

Recoverable encryption items -- p. 68573; 740.8(d)(1)(ii)

Key escrow, key recovery and recoverable encryption software and commodities -- 68574; 742.15(b)(2)

Recovery encryption software and equipment -- p. 68574; 740.8(d)(1)

Encryption items and services with recoverable feature" -- p. 68574

Recoverable items and services -- p. 68574

Recovery encryption items -- 740.8(b)(1); 74-0.8(d)(1)

Key recovery products and services -- Supp. 7

Key recovery products -- Supp. 7

Products under development with key recovery features -- Supp. 7

Encryption products with key recovery features -- Supp. 7

The rule also uses several different phrases to describe the two subcategories of encryption items with recovery features including:

Key escrow and key recovery products (or key escrow and key recovery encryption products or items)  -- p. 68573; 740.8(d)(1)(i); 742.15(b)(2)

Recoverable products -- p. 68573; 740.8(d)(1)(ii); 742.15(b)(2) (or "r [sic] "Recovery encryption products," (which is defined at p. 68575 but appears only once in the rule (at Sec. 748.3(b)(3)).

It is critical given the arcane nature of this technology to adopt a more consistent and precise approach to this terminology.

The phrase "recoverable items and services" should be defined as encompassing two distinct subcategories consisting of "key escrow" and "key recovery products" on the one hand, and "recoverable products", on the other. With respect to the former, eligibility for License Exception KMI largely depends on satisfying the criteria in Supplement Nos. 4 and 5; with respect to the latter, eligibility depends on a case-by-case review of whether the products "allow government officials to obtain, under proper legal authority and without the cooperation or knowledge of the user, the plaintext of the encrypted data and communication.'"This definition from the preamble should be moved to Part 772 and should be clarified by BXA as "recoverable products" are approved over time. If there is truly a difference between "key escrow" and "key recovery", the definitions should make this clear. The regulations treat these as two different terms meaning the same thing. These definitions need to be added to Part 772, and the use of the terms throughout the New Encryption Regulations needs to be made more consistent and precise in order to promote clarity and user friendliness. The definitions should eliminate references to "communications."

12. Encryption ECCNs Require Clarification to Comport with Past Notice

12.1 Make Consistent the Language in the EI Controls Descriptions for ECCNs 5X002. Different phrasing is used in the EI Controls paragraph for ECCNs 5A002, 5D002, and 5E002, We understand this is a drafting error. The wording should be consistent in each of theme ECCNs.

12.2 Clarify in ECCN 5D002 the Application of License Exceptions TMP and BAG. At a minimum, include in ECCN 5DO02 an indication that these License Exceptions are available and revise the last sentence in the first "Note" to ECCN 5D002 to include the underlined portions in the following revised sentence:
"License Exceptions for commodities, other than TMP and BAG, are not applicable".
Otherwise, this phrase appears to take away authority to use TMP and BAG.
12.3 Restore the Bank Interconnect Exception to 5A002 that Was Mistakenly Omitted. The New Encryption Regulations mistakenly omitted the "money or banking" exceptions that previously were transferred to the EAR via the USML XIII(b)(1)(ii) exception and that had been contained in old ECCN 5D13A and in Advisory Note 1.c. to the Information Security section of Group 5 in the March 25, 1996 revision of the EAR (61 Fed. Reg. at 13005). The wording in paragraph h to the Note at the end of ECCN 5A002 does not match the language of the exception in.USML Category XIII(b)(1)(ii), which has (by operation of law and without the requirement of a commodity jurisdiction request), transferred to EAR jurisdiction important banking and financial-related encryption hardware and software. This type of equipment had been eligible for License Exception export under the EAR. The New Encryption Regulations must be revised to restore the exempt status for such products. The most narrow amendment to accomplish this objective would be to insert the underlined language in exception h. to ECCN 5A002 to read as follows:
"h. Cryptographic equipment specially designed, developed, or modified and limited for use in machines for banking or money transactions, such as automatic teller machines, self-service statement printers, or point of sale terminals, or equipment for the encryption of inter-banking, transactions."
A better amendment would be the one proposed by Jim Button of Citicorp, replacing current paragraph h. with the following language:
"h. Cryptographic equipment specially designed, developed, or modified for use in banking or money transactions and restricted to use only in such transactions. Equipment for banking or money transactions include but are not limited to automatic teller machines, self-service statement printers, or point of sale terminals, or equipment for the encryption of inter-banking transactions."
We also support the inclusion of additional financial transaction exceptions proposed by Mr. Button of Citicorp, including new paragraphs i and j as follows:
"i. Cryptographic equipment specially designed, developed or modified for use in conducting financial transactions between a financial institution and its customers, provided that such equipment can be used solely to conduct business with a financial institution and for no other purpose. "

"j. Any cryptographic equipment that is used by a financial institution solely for the purposes of securing its own internal computer systems, networks and other information processing and communications systems and for no other purpose."

12.4 Clarify the Exclusion from 5A002 of Encryption to Protect Passwords or PINs Only. Paragraph f and its predecessor provisions have long been interpreted by NSA, ODTC, and BXA personnel as "decontrolling" the use of encryption that is limited to encryption of passwords, PINs, credit card numbers, and similarly restricted material to prevent unauthorized access to facilities but that does not allow for encryption of data, text, or other media other than that limited to authentication. As currently worded, this paragraph appears to be limited to application of these restricted functions in access control equipment such as ATMs, self-service statement printers, or point of sale terminals. BXA should clarify that this applies to any access control programs, such as those used to run LANs, WANs, or Web servers, or to provide access control or authentication functionality in standalone software applications. This is a clarification, not a change.

Conclusion

Thank you for the opportunity to submit these comments and in advance for your consideration of them. We sincerely wish to work with BXA and other administration officials to help make the New Encryption Regulations more realistic and workable. If you wish to discuss any of these comments, please call the undersigned at 206-936-7896.

Respectfully submitted,

Ira S. Rubinstein
Senior Corporate Attorney

cc: Mr. James Lewis
Mr. Ron Lee

Attachments:

[Attachment 1]

Business Software Alliance
1150  18th Street, N.W.
Suite 700
Washington, D.C. 20036
Tel  202 872 5500
Fax  202 872 5501
Internet  software@bsa.org
Website  http://www.bsa.org

December 2, 1996

The Honorable Albert Gore
The Vice President of the United States
The White House
1600 Pennsylvania Avenue, N.W.
Washington, D.C. 20500

Dear Mr. Vice President:

On behalf of America's leading publishers of computer software, I want to express our dismay at the way the Administration is implementing the October 1encryption policy announcement. BSA said at the time that the announcement was a step in the right direction, but that numerous questions remained. We understand that the Interagency Working Group on Encryption intends to consult with interested parties throughout the process prior to implementation of regulations which is planned for January 1, 1997,and additional information may be available in the very near future. However, given that everything we have seen and heard to date reveals that the government is headed in the absolute wrong direction, we specifically wanted to bring to your direct attention five key principles which underlie BSA's positions and which should but unfortunately do not to appear to, be guiding the Administration.

It appears that significant backtracking has occurred since the October 1 announcement and, therefore, we seriously doubt that the regulations will work, meet computer user demands, or be accepted by the private sector unless the Administration radically changes its approach immediately. If not  the new policy is destined to fail just as its predecessor Clipper efforts. We strongly urge the Administration to focus on what is doable in the real world of millions of Internet users with scores of encryption alternatives from which to choose.

On November 8, BSA provided the Working Group detailed positions on the issues and specific suggestions for regulatory implementation (a copy of the letter is attached).Given the short period left before implementation, five key principles are specifically discussed below which underlie the positions taken in our earlier letter.

____________________

The Business Software Alliance promotes the continued growth of the software industry through its international public policy, education and enforcement programs in 65 countries throughout North America, Europe, Asia and Latin America. BSA worldwide members include the leading publishers of software for personal computers: Adobe Systems Inc., Apple Computer, Inc., Autodesk, Inc., Bentley Systems, Inc., Lotus Development Corp., Microsoft Corp., Novell, Inc., Symantec Corporation and the Santa Cruz Operation. BSA's Policy Council consists of these publishers and other leading computer technology companies including Computer Associates, Digital Equipment Corp., IBM, and Sybase.

(1) VOLUNTARY AND MARKET DRIVEN: To be successful, any key recovery initiative must be voluntary and market driven. Our Companies cannot sell what consumers do not want. As BSA CEOs have discussed with numerous Administration officials, the U.S. software industry is operating in a very competitive, international market -- hundreds of strong encryption products are presently available around the world, many easily down loaded from the Internet. Consumers are demanding strong encryption and it is key to the success of the Internet. Unless users find value in a key recovery functions they will not buy products with this function. The result: American companies lose sales and the government will have failed in its effort to have such products widely deployed.

(2) UNLIMITED KEY LENGTH FOR KEY RECOVERY PRODUCTS: "Key recovery" products should be exportable without key length limit if they include features making the recovery of plain text stored information accessible without the assistance of the individual who has encrypted the information.

As we have explained to the Working Group, there may well be commercial demand for products that enable the recovery of stored encrypted data but them is little, if any, commercial demand for a key recovery function in real-time communications. Accordingly, there should be no such requirement for exportable encryption communications products (or products which do both communications and stored data as long as there are key recovery features for stored data).

Furthermore, key recovery is not key escrow. A purchaser or user of a product being able recover his data is different than, and separate from, the decision as to whether to voluntarily empower a trusted third party to be able to recover the data.

(3) NO INDUSTRIAL POLICY: The government should not dictate "milestones" for company specific plans regarding key recovery products as a condition for interim export control relief . Companies have already announced plans to develop such key recovery products; for example, 35 companies have joined IBM in a key recovery alliance. Numerous other companies already have key recovery products on the market today. There is no need for the government to go down the road of industrial policy by insisting upon becoming a partner with each company. We urge the Administration to adopt the simplest possible process.

(4) EASY EXPORT OF 56 BIT PRODUCTS AS PROMISED: Interim export control relief must permit the export of 56-bit non-key recovery encryption products under Department of Commerce General License procedures that represent actual liberalization. The mere transfer of licensing jurisdiction to Commerce is of little significance unless accompanied with expedited product reviews and realistic licensing requirements. Yet the recent Executive Order states that products which already have export licenses will have to undergo new reviews -- only this time with FBI scrutiny. There is also an urgent need to permit the export of 128-bit encryption for financial applications (when done with appropriate safeguards).

(5) MEETING MARKET DEMANDS NOW AND IN THE FUTURE: Any interim export control relief will be only a mirage unless it meets business needs after two years. Quite simply, there must be interoperability between key-recovery and non key-recovery products. It also must be possible for American companies to service and support the installed base of 56-bit non key-recovery products.

The American software industry needs immediate relief. It is a matter of jobs and international competitiveness. For the Administration's policy to be successful, the government must accept and work with the market, not try to supplant it. It is clear that many in Congress understand the urgency and importance of this issue and the need for strong protection for Internet users. We thought that the October 1 announcement showed that the Administration was also coming to grips with these issues. But now, only a.few weeks later, we wonder.

We have submitted comments to the Government and we stand ready to continue working with you to formulate and implement a market driven, voluntary system which meets consumers' needs.

Sincerely,

Robert W. Holleyman, II
President, BSA

RWH/dlr
Enclosure

[Attachment 2, attachment to BSA letter]

Business Software Alliance
1150 18th Street, N.W.
Suite 700
Washington, D.C. 20036
Tel  202 872 5500
Fax  202 872 5501
Internet  software@bsa.org
Website  http://www.bsa.org

November 8, 1996

Mr. Bruce McConnell
Information Policy & Technology
Office of Management & Budget
New Executive Office Building -- Room 10236
17th & Pennsylvania Avenue, NW

Mr. Ed Appel
National Security Council
Old Executive Office Building -- Room 300
17th & Pennsylvania Avenue, NW
Washington, DC 205034

Dear Bruce and Ed:

On behalf of America's leading publishers of software I wanted to thank you again for the Administration's recent decision to liberalize export controls for commercial encryption products. As BSA said at the time, it is clearly a step in the right direction. However, as we have also explained on numerous occasions since the announcement, there were some notable omissions as well as a great number of unanswered questions. therefore, we sincerely appreciate your willingness to work with us on an expedited basis to hopefully resolve remaining issues and to make further progress.

Based on our recent discussions and meetings with Administration officials, we believe there are four major outstanding areas that need immediate clarification. This letter is intended to provide the Administration with BSA's reactions to what we have heard to date as well as our concrete recommendations for moving forward in these areas.

1. Interim Export Control Relief

BSA's members have said for some time now that the ability to immediately export 56-bit encryption products is critical to maintaining the international competitiveness of the software industry and to providing computer users worldwide with acceptable information security. This also was the major recommendation of the National Research Council Study. Such exports also were clearly permitted under legislation pending before Congress.

Therefore, we welcome your decision to permit the export under Department of Commerce General License beginning January 1, 1997 of products using 57-bit encryption keys. We believe that many American software companies will be ready to ship such products on January 1. We trust that any necessary governments action will be completed by then.

Our specific concerns and suggestions follow:

Licensing Procedures and Rewrite of Regulations: We expect that:

We appreciate the time constraints under which the Administration is laboring; however, we also believe it is essential to get the regulations done right. Therefore we strongly urge you to involve industry associations in the drafting of the new rules. Industry involvement is essential if the Administration is to make good on the promise of achieving liberalized export controls through transfer of jurisdiction over encryption software from State to Commerce. Otherwise the new regime may be more restrictive than the current dual agency regime.

Periodic Upward Adjustments in Key Lengths. We were disappointed that the Administration did not also institute automatic, periodic adjustments in key length that simply would maintain the same level of information protection in the future. Such adjustments are necessary because predictable advances in computing power will make attacks on encrypted information cheaper and easier. This was the rationale behind BSA's earlier recommendation of a "cost of cracking adjustment". The NRC CRISIS Report also called for periodic adjustments. We note again that such adjustments would not further disadvantage the government in performing any required brute force attacks because it is precisely these attacks that benefit from the advances in computing power!

Financial Applications. While the announcement confirms that longer key lengths will continue to be approved for products dedicated to the support of financial applications, no specific decision was made to permit the export of such products with 128 bit encryption keys (under General License GTDU (TSU)). Immediate action in this area is critical as the worldwide financial sector currently demands this level of information security, foreign competitors already are providing it, and safeguards are available to ensure that such products are not used as general confidentiality products. (Industry is familiar and comfortable with the binding standards currently used by NSA -- essentially a "work factor" test in which it would take more effort to reconfigure the program than to do a separate one.) It is essential to remember that if the U.S. Government does not provide immediate export control relief in this area that foreign software companies are now, and will become even more aggressive in, supplying such products -- but without the safeguards -- thereby defeating our government's efforts to limit such encryption worldwide. For example, a German product explicitly advertises on the Internet its ability to prove "highly secure 128 bit transaction encryption despite U.S. export restrictions."

Personal Use Exemption. We also believe further progress needs to be made in the areas of the so-called "personal use exemption" and non-confidentiality uses of encryption. Specifically, reporting requirements should be eliminated or significantly simplified to ease administrative burdens. Moreover, the exemption should be extended to foreign nationals (except those from embargoed countries) employed by U.S. or Canadian companies or subsidiaries/affiliates of U.S. companies.

2. Definition of Key Recovery
Importantly, the Administration's announcement conditions the export of 56-bit encryption products upon "industry commitments to build and to market future products that support key recovery." Such products would have no algorithm restrictions or key length limits.

To be successful, any key recovery initiative must be voluntary and market-driven. Users must see the value of key recovery features and want to use them. American companies cannot sell what users will not buy. In this regard, BSA's members have said for some time that they believe there may well be commercial demand for products that enable the recovery of stored data and that could be saleable worldwide.

We think it also is in the government's interest to see the deployment of such key recovery products for stored data. We believe the government should focus on what is 'doable' in the near term. See what work; get real world experience.

What key recovery means. As we have repeatedly explained, we believe a "key recovery" encryption confidentiality product should be exportable if it includes features making the recovery of "plain text" stored information accessible without the assistance of the individual who has encrypted the information.

Key Recover Is Different Than Key Escrow. A purchaser or user of a product being able to recover his data is different than, and separate from, the decision whether to voluntarily empower a trusted third party to be able to recover the data. Indeed, this distinction between a "key recovery" product that enables third part access to stored information, and "key escrow" which requires such advance third party access, makes all the difference in terms of industry and user acceptance. Quite simply, there should be no requirement that a copy of the user's key, or the means to access or reconstruct the key, be given to anyone (let alone required to do so with government certified agents or with a U.S. entity). Indeed, we also note that even if certain individuals wanted to give a copy of their key to a third party, the existence of a trusted third party infrastructure in each country does not yet exist and could take some time to develop.

Thus, while we believe that in many cases businesses and other entities would have access to keys used by their employees and (in time) commercial key recovery services would be able to recover keys of their subscribers, yet other computer users might choose not to give a copy of their key to anyone (instead perhaps printing out a copy on a floppy disk or paper or content to have it reside in a separate file on their hard drive). The analogy to what people do with their house keys seems apt -- some give a copy to a neighbor or friend, businesses often hold "passkeys" to their employees offices, others put a copy in a safe deposit box or a drawer. Importantly, in each situation the government can obtain the plain text of information by lawfully obtaining the key where ever it might be kept.

Key Recovery Should Be A Condition of Export Only For Stored Data. As we have explained on many occasions, there is little if any commercial demand for a key recovery function in real-time communications. The reason is simple: if the communication is unsuccessful then it is simply tried again until the transfer of information is successfully completed. Users only want the ability to recover in plain text from their stored encrypted information after the fact of transmission. Moreover, software companies have been focusing on meeting this user demand -- recovery of stored data. They understand technically how to do this. In the short run, it is an achievable objective.

We are concerned, however, that some in government seem intent on arguing that because a few products can technically perform key recovery for communications it should be a widespread requirement. To the contrary, our members have seen nothing to suggest that any product developed to date can work on a mass market scale or that there is significant commercial demand for such products.

Therefore, an encryption product that provides key recovery for stored data should be exportable even if it also encrypts communications without key recovery.

Licensing Procedures. Finally, BSA believes that key recovery encryption products for stored data should be exportable:

3. Industry Commitments.

Based on what we have heard to date, unfortunately we believe the Administration may adopt an approach that is based much more on sticks than carrots. We think there is a better way.

The Administration's Tentative Approach. We understand that the Administration may interpret "industry commitments" to building and marketing key recovery products so as to require each company to provide detailed information to the government regarding its plans for developing, producing and marketing key recovery products and services. Moreover, under such an approach companies would have to make resource commitments and concrete benchmarks. The government would review each company's plan every six months. If the government decided that inadequate progress had been made then it could end a company's interim General License to export 56-bit products.

We believe this approach is misguided and unnecessary. Undoubtedly it would subject the Administration to charges of micromanagement and industrial policy. Moreover, such detailed governmental involvement could well threaten the continued success of America's highly dynamic and competitive software and hardware industries. Finally, the burdens of such an approach would limit the ability of companies to participate, thereby reducing the number of companies who could afford to develop key recovery products.

A Better Way. As we explained, we believe that a much more productive and efficient approach is to rely on the fundamental incentive inherent in the government's decision: after two years companies wishing to export encryption programs with long key lengths will only be allowed to do so if those programs and products have key recovery functions for stored data.

We understand that the Administration is nervous about industry actually moving forward with development of key recovery products. But the government already knows that companies will develop and offer key recovery programs for stored data because a number of companies either have such products now, are currently working on such products, or have announced individual or joint efforts to develop such products. They are doing so because users want such products. Indeed, Administration officials have already acknowledged that a "critical mass" of companies are at work on such key recovery products.

We  believe these activities should be sufficient and that any company should be allowed to immediately begin exporting 56-bit products. We do not think it is appropriate or wise to condition each individual company's ability to export 56-bit encryption products on that company's plans to develop or offer key recovery products.

However, if the Administration nevertheless believes such a requirement is necessary, then we strongly urge you to adopt the simplest possible process: make such a commitment to develop or offer key recovery products a term of the General License (or Exception). By exporting products pursuant to the General License, companies would have "self-certified" that they are making the requisite commitment. This would obviate the need for an entire separate regulatory scheme, with letters, meetings, review, etc. We also believe it is essential that the license simply require a commitment to develop or offer key recovery products generally, not a key recovery version of each and every 56-bit product being exported pursuant to the General License.

4. What Happens After Two Years

There are several issues presented by the Administration's announcement that after two years American companies will be unable, as a general proposition, to continue exporting 56 bit encryption products without key recovery.

Interoperability. The Administration maintains that the "domestic use of key recovery will be voluntary, and any American will remain free to use any encryption system domestically." As we have explained all along, we do think that there always will be some demand for non-key recovery encryption programs and products. Thus, we understand the Administration's decision to mean:


The Installed Base. Any interim export control relief will be a mirage unless it meets serious business ends. No commercial user will purchase such products unless they know they can purchase similar products in the future for expanding needs (e.g. a bigger site license), can get replacement products if something is wrong, can install upgrades in the product (even if the encryption remains the same), and can get continued service and customer support. Yet we have heard nothing that addresses these issues. The Administration's decision must be implemented so that whatever is permissible at the end of two years will continue to be so (i.e. approvals already granted must be reasonably interpreted in the future).

BSA and its member companies remain committed to working with Administration to specifically address these important questions and implementation details.

Sincerely,

Becca Gould
Vice President, Public Policy

[Attachment 3]

policy.txt at research.att.com (FTP)

Cryptography Policy and the Information Economy

Matt Blaze
AT&T Labs -- Research
600 Mountain Avenue
Murray Hill, NJ 07974
908-582-5524
mab@research.att.com

DRAFT -- 27 December 1996 -- DRAFT

1. Introduction

This paper is a high-level technical overview of the impact of cryptography on the computing and communications industries, with emphasis on the implications of the Administration's recent cryptography policy initiatives. It represents the best judgement of its author, and does not necessarily reflect the position of AT&T or any other organization.

We argue that unless a fundamental change is made in the direction of our cryptography policy, the United States' dominance in the emerging "information economy" will ultimately be placed in jeopardy. In particular, current policy fails to recognize several increasingly important realities of cryptographic technology:

2. Cryptography and the information economy

Cryptography is concerned with the use of mathematical functions, called "ciphers", that separate the security of a message's content from the security of the media over which it is transmitted. There are several different types of cipher functions. The most familiar are intended to make it difficult to understand the content of message without knowledge of the secret "key". A related type of cipher function can be used to ensure that information has not been altered. Still other functions can be used to establish the origin of digital information ("digital signatures"). Applications of cryptography include securing wired and wireless voice and data traffic against eavesdropping, protecting computer files from unauthorized access, and enabling secure electronic business transactions ("electronic commerce").

Cryptography is not widely used today, especially relative to its potential. This is true for several reasons. First, traditional communications media have historically offered a degree of intrinsic security. For example, it has always been relatively difficult and risky to illegally "tap" a conventional telephone line (the eavesdropper must locate the correct wire pair, arrange for a physical connection and somehow record and recover the traffic without detection). Similarly, data networks, to the extent that they existed at all, have until recently been closed, private systems, with messages routed primarily within the part of the network controlled by the end user's own equipment.

The technology and economics of modern communications and computing systems, on the other hand, strongly favors media that have little or no inherent security. For example, wireless telephones have great advantages in convenience and functionality compared with their familiar wired counterparts and are comprising an increasing proportion of the telephone network. This also makes eavesdropping much easier for curious neighbors, burglars identifying potential targets, and industrial spies seeking to misappropriate trade secrets. Similarly, decentralized computer networks such as the Internet have lower barriers to entry, are much less expensive, are more robust and can be used to accomplish a far greater variety of tasks than the proprietary networks of the past, but, again, at the expense of intrinsic security. The Internet makes it virtually impossible to restrict, or even predict, the path that a particular message will traverse, and there is no way to be certain where a message really originated or whether its content has been altered along the way. It is possible, even common, for electronic mail messages to route through the computers of competitors. There is every reason to believe that these trends will continue, and even accelerate, for the foreseeable future. The users of these networks, however, have learned to depend on the intrinsic security of the technology of the past.

At the same time, electronic communication is becoming increasingly critical to the smooth functioning of our society and our economy and even to protect the safety of human life. Communication networks and computer media are rapidly displacing the less efficient, traditional modes of interaction whose security properties are far better understood. As teleconferences replace face-to-face meetings, electronic mail and fax replace letters, electronic payment systems replace cash transactions, and on-line information services replace written reference material, we enjoy undeniable gains in efficiency, but our assumptions about the reliability of even the most mundane transactions are often dangerously out-of-date. Cryptography is frequently the only viable approach to assuring security as these trends continue.

Fortunately, cryptography is usually a rather inexpensive technology to deploy. Although the cost of developing new cryptographic algorithms and engineering cryptography into specific applications can be significant, the marginal cost, in terms of direct expense and performance impact, of adding cryptographic security can be quite low, especially compared with other options. In the past, cryptography frequently required the use of special-purpose hardware to perform the cipher algorithms. With modern programmable personal computers and microprocessor-based consumer devices (such as cellular telephones), however, it is often possible to implement encryption functions entirely in software, sometimes with little or no performance impact. Similarly, the operational costs of using cryptography can be near zero. Modern key management techniques, such as the use of public-key "certificates", typically require only minimal infrastructural support from on-line secure key management centers. Some applications, including most secure file storage systems, require no trusted infrastructure at all and entail essentially no operational costs.

The availability of cryptography will soon be vitally important to the future of the telecommunications and computing industries, if not to the future of the American economy more generally. This importance will arise less from the direct sale of cryptography services and products than from the enabling effect the existence of cryptography will have an the services that will form the foundation of the future information economy. Cryptography will eventually be embedded in most, perhaps virtually all, communications products and services; it will not be a "stand alone" or "add on" feature as it is today. It is in the direct interest of any industry that hopes to benefit from electronic commerce to encourage wide availability of high-quality, iNexpensive cryptographic products that enable secure communications and commerce.

3. Technical analysis of the administration's current policy

Although there are no restrictions on the sale or use of cryptography within the United States, strict regulations govern the export of products that include encryption features. In general, with narrow exceptions for products for use by US-owned and certain banking industry customers, export licenses are not granted for products that provide more than 40 "bits" of protection. Many domestic vendors supply only exportable-strength cryptography in their domestic products, to ensure inter-operability and to avoid the need to support multiple product lines. The regulations that govern cryptography exports therefore constitute, in effect, de facto restrictions on the encryption available domestically.

The "strength" of an encryption system depends an a number of variables, Including the mathematical properties of the underlying encryption function, the quality of the implementation, and the number of different "keys" from which the user is able to choose. It is very important that a cryptosystem and its implementation be of high quality, since an error or bug in either can expose the data it protects to unexpected vulnerabilities. Although the mathematics of cryptography is not completely understood and cipher design is an exceptionally difficult discipline (there is as yet no general "theory" for designing cipher functions), there are a number of common cipher systems that have been extensively studied and that are widely trusted as building blocks for secure systems. The implementation of practical systems out of these building blocks, too, is a subtle and difficult art, but commercial experience in this area is beginning to lead to good practices for adding high-quality encryption to software and hardware. Users and developers of secure systems can protect against weaknesses in these areas by choosing only cipher functions that have been carefully studied and by ensuring that their implementation follows good engineering practices.

The most easily quantified variable that contributes to the strength of an encryption system is the number of possible keys. Modern ciphers depend on the secrecy of the users "key" and a secret-key system is considered well-designed only if the easiest "attack" involves trying every possible key, one after the other, until the correct one is found. An encryption system can be considered secure only it the number of keys is large enough to make such an effort infeasible. Keys are usually specified as a string of "bits"; adding one bit to the key length doubles the number of possible keys. An important question, then, is the minimum key length sufficient to resist a key search attack in practice. As technology advances and it becomes possible to try keys more quickly and economically, keys that might have once been considered sufficiently long become increasingly vulnerable.

It is almost universally recognized that 40-bit keys provide virtually no protection against such threats today, except against the most casual "attacker". Even 56-bit keys, which are used in the 20-year-old Data Encryption Standard, are too short to protect commercial information given a modestly well-funded attack model. Both the Business Software Alliance's "Minimum Key Length" panel [1] (in which the author participated) and the National Research Council Cryptography Policy [2] study group, have noted the vulnerability of these short keys. The cryptography marketplace, to the extent it exists today is also beginning to understand this, with many customers demanding cryptography that is at least strong enough to withstand a commercially-motivated adversary. The BSA panel's "Minimum Key Lengths" white paper (perhaps the most widely-circulated current reference to address the issue) concludes that secret keys today must be at least 75 bits to withstand a targeted commercial attack, and recommends that newly-deployed systems use secret keys at least 90 bits long to account for expected advances in computer technology that will make shorter keys more vulnerable. (The analysis of "public key" systems is more complex. Public keys generally must be several times longer than this to provide an comparable level of security.) These figures enjoy reasonably broad acceptance among those working in the field. It seems likely that 56-bit keys will soon be regarded by the marketplace as too weak for commercial applications, if they are not already.

There are virtually no technical, performance, or economic benefits to employing keys shorter than needed. The reasons vendors design new systems with short secret keys (40 or 56 bits) usually have to do with extra-technical pressures, such as inter-operability with old systems or, more commonly, to comply with U.S. export requirements.

In the most recent policy documents from the government, the administration proposes to increase the exportable key length from 40 to 56 bits for a two year "transition" period for those companies that can demonstrate that they have plans to incorporate "key recovery" in their products. As noted above, this offer represents only a marginal improvement in security, unlikely to satisfy the majority of applications in which cryptography is required.

It is not surprising that it has been difficult to find a "magic" key length that at once satisfies the security-needs of industry and the wiretapping needs of government. Because of the nature of the problems no such key length can really exist. The reason is that the threat models used by government and industry are not the same. Commercial data security analysis considers the possibility of an adversary who commits significant resources to a targeted attack against a particular key used to protect some data of great interest. On the other hand, government information gathering analysis, while perhaps supported by superior resources and technical expertise than the attacker, in the commercial model, must consider the economics of recovering keys on a routine basis, with only a small percentage of total resources devoted to any particular key. Even if we allow for the possibility that the government's abilities are many times greater than currently estimated, it remains a truism that many commercial data security applications require cryptography stronger than what a government cryptanalysis effort could tolerate.

4. Implications of "key recovery"

The Administration's current policy initiatives encourage the provision of "key recovery" (sometimes called "key escrow") mechanisms in new applications of cryptography. In such systems, copies of keys are automatically deposited, in advance, with some party who can later use them to arrange to provide a backup copy of a key if it should be required at some point in the future. The Administration's original key escrow proposals required that government agencies hold the key copies. More recent proposals suggest that keys could be held by private industry. The latest proposal leaves identity of the key holder unspecified.

A properly designed cryptosystem makes it essentially impossible to recover encrypted data without knowledge of the correct key. Sometimes this can be a double-edged sword; the cost of keeping unauthorized parties out is that if keys are lost or unavailable at the time they are needed, the owner of the encrypted data will be unable to make use of his or her own information. This problem, of balancing secrecy with assurances of continued availability, is a difficult one, and remains an area of active research for which some solutions in a few application areas are starting to emerge.

It is important to distinguish the interests of the government from the needs of the private sector here. While key "recoverability" is a potentially important added-value feature in certain stored data systems, in other applications of cryptography there is no user demand for this feature. The key escrow systems proposed by the administration, on the other hand, are concerned chiefly with recovering encrypted communications traffic. The nature of the key recovery problems of government and industry are, at the outset, quite different.

Key recovery is a difficult, and likely very expensive to solve, technical problem, for reasons that can be observed at several different levels of abstraction. It introduces a fundamental tradeoff, one that is not otherwise present in secure systems. As noted above, in general, cryptography is an intrinsically inexpensive technology; there is little need for "infrastructure" (outside of key certification in some applications) to establish secure communication between two parties. Key recovery, on the other hand, entails by its very nature a complex, expensive, and rather poorly-understood infrastructure. (Ironically, some cryptography vendors could actually reap modest medium-term benefits from rules that mandate key recovery by developing and selling the many new products and services that would be required to support such a policy.)

The most deeply-rooted problem with key recovery is simply that we do not fully understand how to do it. Any key recovery system, by its very nature, reduces the security of a system by increasing its number of points of failure, Unfortunately, we do not understand key recovery well enough to even quantify this reduction in security. The design and implementation of even the simplest encryption systems is an extraordinarily difficult and delicate process. Very small changes frequently introduce fatal security flaws. Ordinary (non-escrowed) encryption systems have conceptually rather simple requirements (for example, the secure transmission of data between two parties) and yet, because there is no general theory for designing them, we still often discover exploitable flaws in fielded systems. Adding key recovery renders even the specification of the problem itself far more complex, making it virtually impossible to assure that such systems work as they are intended to. It is possible, even likely, that lurking in any key recovery system are one or more design weaknesses that allow recovery of data by unauthorized parties. The commercial and academic world simply does not have the tools to analyze or design the complex systems that arise from key recovery. This is not simply an abstract concern. Most of the key recovery or key escrow proposals made to date, including those designed by the National Security Agency (the "Clipper chip") have had weakness discovered after their initial implementation. The NRC report [2] (which the administration incorrectly claims is "broadly consistent" with its recent key escrow proposals) addresses key recovery only to point out that it is an "unproven" concept.

But the most serious problem with "key recovery," beyond the loss of security inherent in their design, may be the enormous expense associated with properly operating the infrastructure required to support it.

According to the Administration (for example, see the December 9, 1996 Commerce Department draft regulations on cryptography export), key recovery centers must be prepared to respond to law enforcement requests for key data 24 hours a day, completing transactions within two hours of receiving each request and in complete secrecy from the target of the investigation. There are thousands of law enforcement agencies in the United States authorized to perform electronic surveillance; the escrow centers must be prepared to identify and respond to any of them within this time frame. If a center also provides commercial data recovery services, it will also have additional private sector customers that it must be prepared to serve and respond to. Even if we imagine relaxing these requirements considerably (e.g., one day response time instead of two hours), there are few, if any, secure systems that operate effectively and economically on such a scale and under such tightly-constrained conditions. It is simply inevitable that key recovery systems that meet the government's requirements will make mistakes in giving out the wrong keys from time to time or will be vulnerable to fraudulent key requests. Key recovery, by its nature, makes encrypted date less secure because the recovery center itself introduces a new target for attack. Perhaps more importantly from a business perspective, a key recovery infrastructure of this kind would be extraordinarily expensive to operate.

The difficulty of designing and operating a reliable, economically scalable key recovery infrastructure arises from the basic requirements of such a system, not simply from a few unresolved technical details. Whether the recovery system uses private key cryptography (with a large database of user keys) or public key cryptography (with a single escrow key for many users), whether the database is split with secret sharing techniques or maintained in a single hardened secure facility, and whether the recovery service provides users' master keys or merely decrypts specific messages as needed, all key recovery system entail the existence of a highly sensitive and highly available secret key or collection of keys that must be maintained in a secure manner over an extended time period. It is this basic requirement that makes the problem of key recovery difficult and expensive, beyond the specific details of any particular implementation.

Finally, there is the problem of user demand and acceptance. Most applications of cryptography (including virtually all that are directly important to to the communications industry or for the development of electronic commerce) do not carry with them any customer-centered demand for key recovery. That is because key recovery is useful to the end-user only for encrypted stored data. Outside of a few specialized, highly regulated environments (e.g., securities trading), there is little reason for a user of cryptography to ever want the ability to recover the "session" keys used to protect past communication traffic. In other words, the substantial cost and risk associated with maintaining a key recovery infrastructure is usually not mitigated by added value to the user; the government is its only beneficiary. The customer derives no benefit from, but pays a significant price for, the key recovery "feature" for communication traffic.

5. Summary

Current U.S. cryptography policy threatens to stifle several of the most promising opportunities for growth in the computing and communications industries. The emerging "information economy" will demand, first and foremost,, an economical, reliable and trustworthy foundation upon which to build the transactions that underlie trade in information. The very technologies that make such a foundation possible are exactly those that current government policy so effectively restricts.

As tempting as it may be to hope that industry can obtain even the most limited short-term relief by negotiating a compromise, the administration's recent policy initiatives offer little to encourage us. In particular, the government now proposes to allow limited exportability of systems with 56-bit keys in exchange for an industry commitment for to build key recovery into future systems over the next two years. As discussed above, neither 56-bit keys nor a key recovery infrastructure are viable solutions from industry's perspective. 56-bit keys are too short to be considered trustworthy; a general key recovery infrastructure is simply too expensive to consider as an option, especially on the scale demanded by even the most conservative expectations of the not-so-distant future.

Unfortunately, it seems unlikely, under the current term under which the cryptography debate is cast, that we will ever find a "compromise'' that satisfies both the government and the needs of industry. There is precious little room for either side to maneuver. A resolution to the issue will require either that industry (and the public at large) abandon its vision of a future information economy in which the trade in information becomes a dominant medium of exchange, unencumbered by physical boundaries, or that the government re-focus its law-enforcement and national security agenda to keep up with, rather than hold back, the natural progress of commercial technology.

6. References

[1] M. Blaze, W. Diffie, R. Rivest, B. Schneier, T. Shimomura, E. Thompson, and M. Wiener. "Minimum Key Lengths for  Symmetric Ciphers to Provide Adequate Commercial Security." January 1996. Available at ftp://research.att.com/dist/mab/keylength.txt.

[2] National Academy of Science, National Research Council. Cryptography's Role in Securing the Information Society. National Academy Press. 1996.

Hypertext by DN and JYA/Urban Deadline